Methods and apparatus to initialize enclaves on target processors

ABSTRACT

Methods, apparatus, systems and articles of manufacture are disclosed to initialize enclaves on target processors. An example apparatus includes an image file retriever to retrieve configuration parameters associated with an enclave file, and an address space manager to calculate a minimum virtual address space value for an enclave image layout based on the configuration parameters, and generate an optimized enclave image layout to allow enclave image execution on unknown target processor types by multiplying the minimum address space value with a virtual address factor to determine an optimized virtual address space value for the optimized enclave image layout.

FIELD OF THE DISCLOSURE

This disclosure relates generally to computer platform applicationsecurity, and, more particularly, to methods and apparatus to initializeenclaves on target processors.

BACKGROUND

In recent years, security enhancements to processors have emerged toallow applications to create protected regions of address space, whichare referred to herein as enclaves. Particular processor instructionsets (e.g., processor microcode) allow implementation of enclaves thatprohibit access to enclave memory areas by code outside of the enclave.Example processor instruction sets to facilitate application enclaves ofa platform are known as SGX (Software Guard Extension) instruction sets.Some example SGX instruction sets permit enclave dynamic memorymanagement that allow adding or removing cache pages to an enclave asneeded during runtime.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is an example enclave memory layout conforming to requirementsof a static software guard extension processor.

FIG. 1B is an example enclave memory layout conforming to requirementsof a dynamic software guard extension processor.

FIG. 2 is an example platform environment to initialize enclaves ontarget processors.

FIG. 3 is an example software guard extension software development kitengine to initialize enclaves on target processors in a mannerconsistent with this disclosure.

FIG. 4 illustrates example enclave memory layouts generated by theexample platform environment of FIG. 2 and the example software guardextension software development kit engine of FIG. 3.

FIGS. 5-7 are flowcharts representative of example machine readableinstructions that may be executed to implement the example platformenvironment of FIG. 2 and the example software guard extension softwaredevelopment kit engine of FIG. 3.

FIG. 8 is a block diagram of an example processor platform structured toexecute the example machine readable instructions of FIGS. 5-7 toimplement the example platform environment of FIG. 2, the examplesoftware guard extension software development kit engine of FIG. 3,and/or the example enclave memory layouts of FIG. 4.

DETAILED DESCRIPTION

Early generation SGX (Software Guard Extension) instruction setspermitted the generation of secure enclaves (referred to herein as“enclaves”) that establish a secure computing environment for softwareapplications and/or data. When the enclave (e.g., an enclave file) isinitialized on a computing platform (e.g., an enclave image), itoperates in a portion of virtual memory (trusted memory) that isinaccessible by external applications and/or the operating system (OS).Functions performed by the enclave image may be invoked by an untrustedapplication (e.g., the OS) and one or more trusted functions of theenclave image may be invoked so that the trusted function can accessenclave data in plaintext, while functions external to the enclave imageare denied such plaintext access.

Generally speaking, SGX enclaves include a build-time phase, a load-timephase, and a runtime phase. During the example build-time phase, sourcecode (e.g., developed by an independent software vendor (ISV)) issupplied to a compiler and linker, which may utilize one or more signingtools of an SGX software development kit (SDK) to generate an enclaveexecutable file. Additionally, the example source code includesconfiguration information that has one or more requirements for theenclave, such as component requirements (e.g., a size of heaps, a sizeof stacks, a number of threads, etc). The one or more signing tools ofthe SGX SDK determine a virtual size of the enclave and addresses of theone or more components. Further, during the build-timecompiling/linking, address information and/or size information (of pagetypes) are written to a corresponding executable file to be used duringthe load-time phase. In some examples, address information, sizeinformation and/or page information generated by the one or more signingtools of the SGX SDK are referred to as metadata.

During the example load-time phase, the enclave executable file isloaded into an enclave page cache (EPC), which results in an enclaveimage. As described in further detail below, the example EPC is a securememory structure that can be accessed using instructinos from an SGXinstruction set associated with a processor developed to handleenclaves. During this load-time phase, corresponding code and/or data ofthe enclave file is loaded along with one or more static componentsidentified by the metadata created by the one or more signing tools ofthe SGX SDK. The loading activity may include one or more SGXinstructions such as ECREATE, EADD (adds pages needed by memorystructures specified by the metadata) and/or EEXTEND. Additionally, eachenclave file includes an associated digital signature to be verified toa subsequent measurement. The measurement occurs in response to aparticular SGX instruction named EINIT. After the EINIT instruction isinvoked, other instructions listed above cannot be used any more, and ameasurement of the enclave occurs that can be compared to the digitalsignature, thereby allowing a (remote) party to authenticate the enclavewith an expected measurement value. Remote parties may include theoperating system (OS) and/or applications and/or services running onremote platform(s).

In the event of a successful measurement, the runtime phase may proceed,in which the enclave initialization code (e.g., trusted code runninginside the enclave) determines whether to use static or dynamicheap/stacks. Prior to the EINIT instruction, the enclave cannot run.However, untrusted runtime libraries and/or drivers must collaboratewith page allocation for any interaction to preserve the secure natureof enclave operation(s).

During the runtime phase, the enclave image operates in trusted memoryand includes enclave data and/or enclave code having any number ofthreads (e.g., a thread control structure (TCS)). As described above, inthe event a remote party (e.g., an application and/or OS) wishes toaccess one or more services of the enclave image, an integrityverification occurs (measurement) prior to the runtime phase to ensurethat the enclave image has not been compromised. The measurementincludes parameters of the enclave image such as, but not limited to, asize of virtual memory required for operation (e.g., an enclave virtualsize), a size of a static heap, a number of threads, a size of eachthread (including thread stack sizes, thread local storage, thread data,etc.), or a size of a dynamic heap (e.g., for enclave images thatsupport dynamic memory management). While an independent software vendor(ISV) develops and/or otherwise writes code for an enclave file, themeasurement occurs after the enclave file is loaded into virtual memoryas an enclave image. A enclave in memory includes at least amemory-mapped executable file developed by the ISV, one or more stacks(e.g., multiple stacks for multi-threaded applications), and a heap. Thecorresponding enclave image in memory includes a loaded version of thesecomponents in which those components are aligned and padded. During aloading phase of the enclave file, virtual memory is allocated (e.g.,pages), and static components are allocated (e.g., a static heap, staticthread(s)). In the event that the SGX instruction set of the processorincludes dynamic memory management capabilities, dynamic components maybe used (e.g., a dynamic heap, dynamic thread(s)), etc.). As describedin further detail below, dynamic components do not exist until runtime.

In the illustrated example of FIG. 1A, a first enclave memory layout 100includes an enclave image 102, a static heap 104, a first static thread106, and a second static thread 108. In particular, the first enclavememory layout 100 conforms to requirements of a first SGX instructionset of a corresponding processor that is capable of handling staticcomponents only (e.g., a “static SGX processor”), in which theparticular arrangement of components within the first enclave memorylayout 100 cannot change during runtime. In some examples, the staticSGX processor refers to relatively early generations of SGX processorsnamed “SGX 1.0”. As discussed in further detail below, other (e.g., morerecent generations) SGX instruction sets (e.g., microcode of more recentSGX processors) are capable of handling both static components, as wellas dynamic components that may be invoked and/or otherwise change duringruntime. In some examples, relatively recent generations of SGXprocessors (e.g., “dynamic SGX processors”) are named “SGX 2.0”. Theexample first enclave memory layout 100 is allocated to virtual memoryhaving a first virtual size 110 represented by a dashed line. As such,when the example first enclave memory layout 100 is loaded, acorresponding measurement will be based on the example first virtualsize 110 of allocated virtual memory, the example enclave image 102, theexample static heap 104, the example first static thread 106, and theexample second static thread 108.

In the illustrated example of FIG. 1B, a second enclave memory layout130 includes the enclave image 102, the static heap 104, the firststatic thread 106, and the second static thread 108. However, becausethe example second enclave memory layout 130 is targeted for a secondSGX processor having a second SGX instruction set that is capable ofhandling dynamic components (e.g., a “dynamic SGX processor,” or “SGX2.0”), the example second enclave memory layout 130 further includes,during runtime, an example dynamic heap 132, an example first dynamicthread 134, and an example second dynamic thread 136. Each of the firstdynamic thread 134 and the example second dynamic thread 136 may includecorresponding thread local storage (TLS) components, thread data (TD)components, state save areas (SSAs) and/or stacks. Additionally, toaccommodate for the dynamic components the example second enclave memorylayout 130 is allocated to virtual memory having a second virtual size138 represented by a dashed line. As such, when the example secondenclave memory layout 130 is loaded, a corresponding measurement will bebased on the example second virtual size 138 of allocated virtualmemory, the example enclave image 102, the example static heap 104, theexample first static thread 106, and the example second static thread108, but the example dynamic heap 132, the example first dynamic thread134, and the example second dynamic thread 136 will not be part of thatmeasurement.

While the same example enclave image 102 is used for the example firstenclave memory layout 100 and the example second enclave memory layout130, the measurements between these two layouts will be different. Inparticular, when comparing the example first enclave memory layout 100and the example second enclave memory layout 130, two differentmeasurements will result due to the difference in size of the exampleallocated first virtual size 110 and the example allocated secondvirtual size 138 of the virtual memory. As such, the ISV is burdenedwith a responsibility to manage two separate memory layouts depending onwhich target processor type will execute the enclave. In some examples,the ISV may require adjustments to its attestation infrastructure toaccommodate for different measurements that may occur depending ondifferent types of SGX capabilities (e.g., SGX processors with onlystatic component capabilities, SGX processors with static and dynamiccomponent capabilities).

Example methods, apparatus, systems and/or articles of manufacturedisclosed herein facilitate processor agnostic enclave image layoutloading, such as enclave image 102 loading on either static memorymanagement SGX processors (static SGX processors) or dynamic memorymanagement SGX processor (dynamic SGX processors) without further codingefforts by the ISVs. As described above, ISVs are typically responsiblefor coding and/or otherwise designing enclave files to be executed insecure virtual memory as an enclave image, such as the example enclaveimage 102 of FIGS. 1A and/or 1B. Examples disclosed herein permit an ISVto deploy an enclave image file to a target platform when the targetprocessor type (e.g., static SGX processor, dynamic SGX processor) isunknown, thereby removing ISV concern for specifically tailoring theenclave file for one or more memory management instructions that arespecific to a target SGX processor. Additionally, examples disclosedherein determine and/or otherwise detect a type of the target SGXprocessor after the loading phase is complete to inform the enclavememory layout in virtual memory of which memory management routines areavailable during runtime (e.g., static component memory management ordynamic component memory management).

FIG. 2 illustrates an example platform environment 200 to initializeenclave files on target processors. In the illustrated example of FIG.2, the platform environment 200 includes a processor 202 containing asoftware guard extension (SGX) instruction set 204. In some examples,the example processor 202 is referred to as an SGX processor by virtueof a type of SGX instruction set 204. The example SGX instruction set204 may be a static component instruction set 204A (e.g., a legacy orearly generation instruction set), or a dynamic component instructionset 204B (e.g., a more recent generation instruction set that is capableof adding and/or removing dynamic components from the enclave withoutaltering its measurement). The example SGX instruction set 204 includeshardware instructions (e.g., processor microcode) used by an operatingsystem of the platform environment 200 to implement an enclave file foran executable application. The example platform environment 200 alsoincludes physical memory 206 (e.g., a cache memory, dynamic randomaccess memory (DRAM), synchronous DRAM and/or other volatile memory)that may store data and/or instructions for the example platformenvironment 200. The example physical memory 206 includes an exampleenclave page cache (EPC) 208 that may include any number of pages 210.

The example EPC 208 is a secure memory structure that can be accessedusing instructions from the example SGX instruction set 204. In theillustrated example of FIG. 2, the EPC 208 provides access controlmechanisms to protect the integrity and confidentiality of the one ormore pages 210. In some examples, the EPC 208 maintains a coherencyprotocol and may be implemented as a dedicated synchronous RAM of theexample processor 202. In some examples, the EPC 208 is implemented viaa Crypto Memory Aperture (CMA) mechanism.

The example physical memory 206 also includes an example SGX softwaredevelopment kit (SDK) image file 212 that is loaded on a virtual memory214 as an SGX engine 216 by the example processor 202. Additionally, theexample virtual memory 214 includes an enclave image 218 that is loadedand instantiated by the example SGX engine 216. The example enclaveimage 218 also includes an associated measurement value 220 that isdetermined after the enclave image 218 is loaded into virtual memory,but prior to runtime.

In operation, the example enclave image 218 may execute during runtimeto perform one or more operations based on a request. For example, abanking client may invoke a function call to determine a measurementvalue of the enclave image 218 so that it may be compared against aprior known value that is deemed valid and/or otherwise trustworthy. Inthe event the measurement value stored by the example banking clientmatches the example measurement value 220 associated with the exampleenclave image 218, then one or more authorized function calls may bemade to the enclave image 218. However, no function calls are availableto cause the enclave image 218 to reveal its data and/or code inplaintext format, even if such requests originate from an OS kernel. Assuch, enclave images 218 implemented by SGX processors 202 are deemedtrustworthy containers within which code may be executed.

However, ISVs that develop enclave files to be loaded as enclave images218 in virtual memory 214 typically tailor their building, compilingand/or linking of the enclave files in a manner that satisfies a targetprocessor type (e.g., a type of SGX instruction set available on theexample platform environment 200). As described above in connection withFIGS. 1A and 1B, enclave memory layouts will differ based on a targetprocessor type that allocates virtual memory resources in a manner thatcauses measurements for the same enclave image file to be different fromone platform environment to another platform environment. Additionally,once an enclave image 218 is loaded, it must be instantiated and/orotherwise initialized for runtime with information that reveals whichtype of memory management instruction set is available. For example, ifthe example platform environment 200 includes a legacy and/or oldergeneration SGX instruction set that is not capable of dynamic memorymanagement during runtime (e.g., a static SGX processor), then theenclave image 218 must use only those memory management instructionsrelated to static memory management. On the other hand, in the event theexample platform environment 200 includes a more-recent generation SGXinstruction set that is capable of dynamic memory management duringruntime (e.g., a dynamic SGX processor), then the enclave image shoulduse such dynamic memory management instructions to take advantage ofperformance and/or memory management enhancements (e.g., EPCminimization and/or footprint reduction).

FIG. 3 includes additional detail of the example SGX engine 216 of FIG.2. In the illustrated example of FIG. 3, the SGX engine 216 includes animage file manager 302, a configuration parameter manager 304, anaddress space manager 306, an enclave initializer 308, and an SGXidentifier 310. In operation (during build-time), the example image filemanager 302 retrieves an enclave image file (e.g., from an ISV). In someexamples, enclave image files are stored on disk and transferred to arelatively faster storage device, such as the example physical memory206 of FIG. 2. Ultimately, the target/desired enclave image file isloaded (during load-time) into virtual memory 214 in a particular layoutfor runtime execution (e.g., see FIGS. 1A and 1B), which includes anynumber of additional components needed for such execution (e.g., heaps,stacks, threads, etc.). During the example build-time phase, the exampleconfiguration parameter manager 304 extracts configuration parametersfrom the enclave image file. Configuration parameters include, but arenot limited to a number of static threads required for runtime, a sizeof a static heap during runtime, a size of a dynamic heap duringruntime, a number of thread stacks and their associated sizes, etc.

Based on the configuration parameters extracted by the exampleconfiguration parameter manager 304, the example address space manager306 calculates (e.g., during the build-time phase whencompiling/linking) a virtual address space value. In some examples, theconfiguration parameter manager 304 calculates a maximum possibleaddress space value that is based on a maximum amount of resources thatcould be requested and/or otherwise demanded by the enclave image 218during execution. Determining the maximum possible address space valuemay be accomplished in a manner consistent with U.S. Patent PublicationNo. 2014-0006711 A1, filed on Jun. 27, 2012, entitled “Method, System,and Device for Modifying a Secure Enclave Configuration Without Changingthe Enclave Measurement,” which is incorporated by reference herein inits entirety. The maximum possible address space value specifies, forexample, a maximum number of threads supported by an application of theenclave image 218 under any circumstances, which may also include amaximum number of thread control structures, a maximum or upper bound ofthe heap and/or stack sizes, etc. However, in some examples determininga maximum address space value may accommodate an enclave image thatoperates in connection with a first type of SGX instruction set, but maynot accommodate that enclave image that operates in connection with asecond type of SGX instruction set.

Returning to the illustrated example of FIG. 1A, the example firstenclave memory layout 100, which is associated with an SGX instructionset capable of handling only static components, has an associated firstvirtual size 110. For the sake of example, the first virtual size 110 isdetermined to be a maximum address space value to accommodate theassociated enclave image 102 and all components (e.g., two threads) thatit might require during operation. On the other hand, in the event theenclave image 102 is to execute in connection with an SGX instructionset capable of handling dynamic components, as shown in the illustratedexample of FIG. 1B, then any maximum address space value determinationperformed earlier in connection with the alternate SGX processor (e.g.,the SGX processor capable of only handling static components) would notbe appropriate and/or otherwise successful on that alternate targetprocessor. Instead, the example second virtual size 138 of FIG. 1B wouldbe required for successful operation of the enclave image 102 with thedynamic instruction set.

To determine a virtual address size for an enclave of interest that canexecute in connection with either the example static componentinstruction set 204A or the example dynamic component instruction set204B (while maintaining a measurement value that is consistent in eithersituation), the example address space manager 306 calculates a minimumaddress space required for a target application that is to use theexample enclave image 102. In particular, because both static memorylayouts (e.g., the example first enclave memory layout 100) and dynamicmemory layouts (e.g., the example second enclave memory layout 130)must, at a minimum, include all static components during a loadingphase, the example address space manager 306 determines a virtualaddress space that includes the example enclave image 102, the examplestatic heap 104, the example first static thread 106, and the examplesecond static thread 108. To generate an enclave memory layout that iscompatible with both types of SGX processors, and to prevent any ISVefforts and/or concerns regarding generating an enclave memory layoutthat conforms to a particular measurement value, the example addressspace manager 306 applies a virtual address multiplication factor whendetermining a virtual address size value. The virtual addressmultiplication factor may be any numeric value that results in anincrease of a minimum address space value to an adjusted value.

FIG. 4 illustrates example enclave memory layouts 400. In theillustrated example of FIG. 4, the example first enclave memory layout100 from FIG. 1A is shown for comparison purposes. The example addressspace manager 306 determines that a minimum virtual address space thatis represented by the example first virtual size 110 (see dashed line)under the assumption that both the example first static thread 106 andthe example second static thread 108 will be required when the enclaveis invoked by an application. While the example first virtual size 110of FIG. 4 is shown as a rectangular region, the example first virtualsize 110 may also be represented in a numeric manner, such as an amountof memory in bytes. To generate an enclave memory layout that iscompatible with any type of SGX processor (e.g., static SGX processorswith microcode/instruction sets that can handle static components,dynamic SGX processors with microcode/instruction sets that can handledynamic components), the example address space manager 306 multipliesthe example first virtual size 110 by a multiplication factor todetermine an optimized virtual size 402 that includes a dynamic virtualcontainer 404. As such, an optimized memory enclave layout 406 resultsduring the loading phase of the enclave image 102. Additionally,regardless of whether the enclave image 102 is to be loaded inconnection with a legacy SGX processor (e.g., only capable of staticmemory management) or a relatively newer generation of SGX processor(e.g., capable of dynamic memory management), the same optimized memoryenclave layout 406 may be used.

For example, the illustrated example of FIG. 4 includes the optimizedmemory enclave layout 406 that was loaded in connection with a platformusing a relatively newer generation of SGX processor (see optimizedmemory enclave layout 406 referenced by 408). At the time ofmeasurement, the static contents of the optimized memory enclave layout410 have not changed, and the optimized virtual size 402 has notchanged, which results in the same measurement values during the enclaveloading phase regardless of the type of SGX processor being used.Additionally, in the event the target platform is using the relativelynewer generation of SGX processor (e.g., a processor using the exampledynamic component instruction set 204B of FIG. 2), then one or moredynamic runtime components may use the example dynamic virtual container404.

In other words, when the ISV prepares to build, load and instantiate anenclave file for use on a platform (e.g., for which the ISV does notknow or care about the particular SGX instruction set capabilities),examples disclosed herein permit such building, loading and instatiationto occur so that the instantiated enclave can operate with either an SGXinstruction set that includes static capabilities only, or dynamiccapabilities. Further, any measurement taken of the example layout afterthe loading phase (when measurements occur) will be the same regardlessof the SGX processor type used because, in part, the allocated virtualaddress size will be the same in all instances.

The example enclave instantiator 308 instantiates the example optimizedmemory enclave layout 406, and the example SGX identifier 310 informsthe optimized memory enclave layout 406 of the type of SGX instructionsavailable to it. In particular, the example SGX identifier 310 detectsan architecture type of the processor, such as by way of invoking and/orotherwise querying a CPU_ID command/opcode. In the event the queryindicates that the processor is of a legacy type, then the example SGXidentifier 310 associates the optimized memory enclave layout 406 with astatic memory flag so that when the enclave image invokes one or morememory management instructions, it does so in view of the capabilitiesof the current platform. On the other hand, in the event the queryindicates that the processor is of a relatively newer type that iscapable of dynamic memory management, then the example SGX identifier310 associates the optimized memory enclave layout 406 with a dynamicmemory flag.

While an example manner of implementing the platform environment 200 ofFIG. 2 is illustrated in FIGS. 1-4, one or more of the elements,processes and/or devices illustrated in FIGS. 1-4 may be combined,divided, re-arranged, omitted, eliminated and/or implemented in anyother way. Further, the example image file manager 302, the exampleconfiguration parameter manager 304, the example address space manager306, the example enclave initializer 308, the example SGX identifier 310and/or, more generally, the example SGX engine 216 of FIGS. 2 and/or 3may be implemented by hardware, software, firmware and/or anycombination of hardware, software and/or firmware. Thus, for example,any of the example image file manager 302, the example configurationparameter manager 304, the example address space manager 306, theexample enclave initializer 308, the example SGX identifier 310 and/or,more generally, the example SGX engine 216 of FIGS. 2 and/or 3 could beimplemented by one or more analog or digital circuit(s), logic circuits,programmable processor(s), application specific integrated circuit(s)(ASIC(s)), programmable logic device(s) (PLD(s)) and/or fieldprogrammable logic device(s) (FPLD(s)). When reading any of theapparatus or system claims of this patent to cover a purely softwareand/or firmware implementation, at least one of the example image filemanager 302, the example configuration parameter manager 304, theexample address space manager 306, the example enclave initializer 308,the example SGX identifier 310 and/or, more generally, the example SGXengine 216 of FIGS. 2 and/or 3 is/are hereby expressly defined toinclude a tangible computer readable storage device or storage disk suchas a memory, a digital versatile disk (DVD), a compact disk (CD), aBlu-ray disk, etc. storing the software and/or firmware. Further still,the example platform environment 200 of FIGS. 1-4 may include one ormore elements, processes and/or devices in addition to, or instead of,those illustrated in FIGS. 1-4, and/or may include more than one of anyor all of the illustrated elements, processes and devices.

Flowcharts representative of example machine readable instructions forimplementing the platform environment 200 of FIGS. 1-4 are shown inFIGS. 5-7. In these examples, the machine readable instructions compriseprogram(s) for execution by a processor such as the processor 812 shownin the example processor platform 800 discussed below in connection withFIG. 8. The program(s) may be embodied in software stored on a tangiblecomputer readable storage medium such as a CD-ROM, a floppy disk, a harddrive, a digital versatile disk (DVD), a Blu-ray disk, or a memoryassociated with the processor 812, but the entire program(s) and/orparts thereof could alternatively be executed by a device other than theprocessor 812 and/or embodied in firmware or dedicated hardware.Further, although the example program(s) is/are described with referenceto the flowcharts illustrated in FIGS. 5-7, many other methods ofimplementing the example platform environment 200 may alternatively beused. For example, the order of execution of the blocks may be changed,and/or some of the blocks described may be changed, eliminated, orcombined.

As mentioned above, the example processes of FIGS. 5-7 may beimplemented using coded instructions (e.g., computer and/or machinereadable instructions) stored on a tangible computer readable storagemedium such as a hard disk drive, a flash memory, a read-only memory(ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, arandom-access memory (RAM) and/or any other storage device or storagedisk in which information is stored for any duration (e.g., for extendedtime periods, permanently, for brief instances, for temporarilybuffering, and/or for caching of the information). As used herein, theterm tangible computer readable storage medium is expressly defined toinclude any type of computer readable storage device and/or storage diskand to exclude propagating signals and to exclude transmission media. Asused herein, “tangible computer readable storage medium” and “tangiblemachine readable storage medium” are used interchangeably. Additionallyor alternatively, the example processes of FIGS. 5-7 may be implementedusing coded instructions (e.g., computer and/or machine readableinstructions) stored on a non-transitory computer and/or machinereadable medium such as a hard disk drive, a flash memory, a read-onlymemory, a compact disk, a digital versatile disk, a cache, arandom-access memory and/or any other storage device or storage disk inwhich information is stored for any duration (e.g., for extended timeperiods, permanently, for brief instances, for temporarily buffering,and/or for caching of the information). As used herein, the termnon-transitory computer readable medium is expressly defined to includeany type of computer readable storage device and/or storage disk and toexclude propagating signals and to exclude transmission media. As usedherein, when the phrase “at least” is used as the transition term in apreamble of a claim, it is open-ended in the same manner as the term“comprising” is open ended.

The program 500 of FIG. 5 begins at block 502 where the example imagefile manager 302 retrieves an enclave image file, such as an enclaveimage file developed by an ISV and stored on disk and/or the examplephysical memory 206. The example configuration parameter managerextracts configuration parameters from the example enclave image file(block 504), which may include information related to a number of staticthreads required for runtime, a size of a static heap during runtime, asize of a dynamic heap during runtime, a number of thread stacks and/orassociated sizes. To generate an enclave memory layout that iscompatible with any available processor type, the example address spacemanager 306 calculates virtual address space (block 506).

FIG. 6 includes additional detail associated with calculating virtualaddress space of block 506. In the illustrated example of FIG. 6, theexample address space manager 306 calculates a minimum address space(block 602). In some examples, the address space manager 306 determinesthe minimum address space required for runtime based on the retrievedconfiguration parameters, which identify how many threads the exampleenclave image is to provide. As described above, the example enclaveimage may be capable of instantiating any number of threads, but only ifsuch threads are first allocated virtual memory to be used at runtime.To ensure that an enclave image will work on an un-identified targetplatform having either an SGX processor capable of static memorymanagement only, or capable of dynamic memory management, the exampleaddress space manager 306 applies a virtual address multiplicationfactor to the minimum address space size (block 604). In some examples,the virtual address space size is determined by enclave configurationinformation (e.g., the metadata), which may include the number of staticthreads, the number of dynamic threads, sizes of static and/or dynamicheaps, and/or stack sizes. As described above in connection with FIG. 4,the example virtual address multiplication factor results in anadditional amount of allocated virtual memory during load time, andshown as the example dynamic virtual container 404. During the enclaveloading phase, the example address space manager 306 allocates the newlycalculated virtual address space (block 606), such as the optimizedvirtual size 402 to generate the optimized memory enclave layout 406shown in FIG. 4.

The example enclave initializer 308 initializes and/or otherwiseinstantiates the example optimized memory enclave layout (block 508). Insome examples, the enclave initializer 308 instantiates the optimizedmemory enclave layout in a manner consistent with U.S. PatentPublication No. 2014-0006711 A1, filed on Jun. 27, 2012, entitled“Method, System, and Device for Modifying a Secure Enclave ConfigurationWithout Changing the Enclave Measurement,” which is incorporated byreference herein in its entirety. Additionally, the example enclaveinitializer 308 may instantiate the optimized memory enclave layout in amanner consistent with U.S. patent application Ser. No. 14/849,222,filed on Sep. 9, 2015, entitled “Application Execution Enclave MemoryPage Cache Management Method and Apparatus,” which is incorporated byreference herein in its entirety.

At runtime, the example SGX identifier 310 configures runtime parametersfor the example optimized memory enclave layout (block 510). FIG. 7includes additional detail associated with configuring the runtimeparameters for the example optimized memory enclave layout of block 510.In the illustrated example of FIG. 7, the SGX identifier 310 detects aprocessor architecture type of the processor (block 702). As describedabove, the example SGX identifier 310 may invoke one or moreopcodes/commands to determine and/or otherwise detect the architecturetype of the processor, such as the CPU_ID opcode. If the example SGXidentifier 310 determines that the processor is of a legacy type (block704), then the example SGX identifier 310 associates the optimizedmemory enclave layout 406 with a static memory flag (block 706), therebyallowing static memory management instructions to be used with theoptimized memory enclave layout 406. On the other hand, in the event theexample SGX identifier 310 determines that the processor is capable ofdynamic memory management capabilities (block 704), then the example SGXidentifier 310 associates the optimized memory enclave layout 406 with adynamic memory flag (block 708), thereby allowing dynamic memorymanagement instructions to be used with the optimized memory enclavelayout 406.

FIG. 8 is a block diagram of an example processor platform 800 capableof executing the instructions of FIGS. 5-7 to implement the SGX engine216 of FIGS. 1-4. The processor platform 800 can be, for example, aserver, a personal computer, an Internet appliance, a gaming console, aset top box, or any other type of computing device.

The processor platform 800 of the illustrated example includes aprocessor 812. The processor 812 of the illustrated example is hardware.For example, the processor 812 can be implemented by one or moreintegrated circuits, logic circuits, microprocessors or controllers fromany desired family or manufacturer. In the illustrated example of FIG.8, the processor 812 includes one or more example processing cores 815configured via example instructions 832, which include the exampleinstructions of FIGS. 5-7 to implement the example SGX engine 216 ofFIGS. 1-4.

The processor 812 of the illustrated example includes a local memory 813(e.g., a cache). The processor 812 of the illustrated example is incommunication with a main memory including a random access memory (RAM)814 and a read only memory (ROM) (e.g., non-volatile memory) 816 via abus 818. The RAM 814 may be implemented by Synchronous Dynamic RandomAccess Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUSDynamic Random Access Memory (RDRAM) and/or any other type of randomaccess memory device. The ROM 816 may be implemented by flash memoryand/or any other desired type of memory device. Access to the mainmemory 814, 816 is controlled by a memory controller.

The processor platform 800 of the illustrated example also includes aninterface circuit 820. The interface circuit 820 may be implemented byany type of interface standard, such as an Ethernet interface, auniversal serial bus (USB), and/or a PCI express interface.

In the illustrated example, one or more input devices 822 are connectedto the interface circuit 820. The input device(s) 822 permit(s) a userto enter data and commands into the processor 812. The input device(s)can be implemented by, for example, an audio sensor, a microphone, acamera (still or video), a keyboard, a button, a mouse, a touchscreen, atrack-pad, a trackball, isopoint and/or a voice recognition system.

One or more output devices 824 are also connected to the interfacecircuit 820 of the illustrated example. The output devices 824 can beimplemented, for example, by display devices (e.g., a light emittingdiode (LED), an organic light emitting diode (OLED), a liquid crystaldisplay, a cathode ray tube display (CRT), a touchscreen, a tactileoutput device, a printer and/or speakers). The interface circuit 820 ofthe illustrated example, thus, typically includes a graphics drivercard, a graphics driver chip or a graphics driver processor.

The interface circuit 820 of the illustrated example also includes acommunication device such as a transmitter, a receiver, a transceiver, amodem and/or network interface card to facilitate exchange of data withexternal machines (e.g., computing devices of any kind) via a network826 (e.g., an Ethernet connection, a digital subscriber line (DSL) tofacilitate exchange of data within a similar machine platform (e.g., acommunication bus), a telephone line, coaxial cable, a cellulartelephone system, etc.).

The processor platform 800 of the illustrated example also includes oneor more mass storage devices 828 for storing software and/or data.Examples of such mass storage devices 828 include floppy disk drives,hard drive disks, compact disk drives, Blu-ray disk drives, RAIDsystems, and digital versatile disk (DVD) drives. In some examples, themass storage device 830 may implement the example subscription database110.

The coded instructions 832 of FIGS. 5-7 may be stored in the massstorage device 828, in the volatile memory 814, in the non-volatilememory 816, and/or on a removable tangible computer readable storagemedium such as a CD or DVD 836.

From the foregoing, it will be appreciated that the above disclosedmethods, apparatus and articles of manufacture reduce ISV involvementwhen developing and/or deploying enclave services so that multipledifferent target processor platforms can implement such enclaveservices. Accordingly, ISV enclave developers do not need to createand/or otherwise design specific enclaves on a platform-by-platformbasis. Additionally, because examples disclosed herein apply a virtualaddress multiplication factor to the enclave image, the enclave loadedon the platform will exhibit the same measurement regardless of whetherthe target processor is able to handle static memory management ordynamic memory management during runtime.

Example methods, apparatus, systems and articles of manufacture toinitialize enclaves on target processors is disclosed herein. Furtherexamples and combinations thereof include the following.

Example 1 is an apparatus to generate a processor agnostic enclave imagelayout, including an image file retriever to retrieve configurationparameters associated with an enclave file, and an address space managerto: calculate a minimum virtual address space value for an enclave imagelayout based on the configuration parameters, and generate an optimizedenclave image layout to allow enclave image execution on unknown targetprocessor types by multiplying the minimum address space value with avirtual address factor to determine an optimized virtual address spacevalue for the optimized enclave image layout.

Example 2 includes the apparatus as defined in example 1, wherein theimage file retriever is to retrieve a number of candidate threadsassociated with the enclave file.

Example 3 includes the apparatus as defined in example 2, wherein theconfiguration parameters include a static heap size associated with thenumber of candidate threads associated with the enclave file.

Example 4 includes the apparatus as defined in example 3, wherein theaddress space manager is to calculate the minimum virtual address spacevalue based on the number of candidate threads and the static heap size.

Example 5 includes the apparatus as defined in example 1, wherein theaddress space manager is to generate the optimized enclave image layoutwith static enclave components and the optimized virtual address spacevalue prior to an instantiation phase to facilitate a measurement of theoptimized enclave image layout.

Example 6 includes the apparatus as defined in example 5, wherein themeasurement of the optimized enclave image layout is the same for all ofthe unknown processor types.

Example 7 includes the apparatus as defined in example 1, furtherincluding a software guard extension (SGX) identifier to determine atype of a respective one of the unknown processor types.

Example 8 includes the apparatus as defined in example 7, wherein thetype of the respective one of the unknown processor types includes atleast one of a static SGX processor or a dynamic SGX processor.

Example 9 includes the apparatus as defined in example 7, wherein theSGX identifier is to associate the optimized enclave image layout with atarget enclave instruction set based on the determined type of therespective one of the unknown processor types.

Example 10 includes a method to generate a processor agnostic enclaveimage layout, including retrieving configuration parameters associatedwith an enclave file, calculating a minimum virtual address space valuefor an enclave image layout based on the configuration parameters, andgenerating an optimized enclave image layout to allow enclave imageexecution on unknown target processor types by multiplying the minimumaddress space value with a virtual address factor to determine anoptimized virtual address space value for the optimized enclave imagelayout.

Example 11 includes the method as defined in example 10, furtherincluding retrieving a number of candidate threads associated with theenclave file.

Example 12 includes the method as defined in example 11, wherein theconfiguration parameters include a static heap size associated with thenumber of candidate threads associated with the enclave file.

Example 13 includes the method as defined in example 12, furtherincluding calculating the minimum virtual address space value based onthe number of candidate threads and the static heap size.

Example 14 includes the method as defined in example 10, furtherincluding generating the optimized enclave image layout with staticenclave components and the optimized virtual address space value priorto an instantiation phase to facilitate a measurement of the optimizedenclave image layout.

Example 15 includes the method as defined in example 14, wherein themeasurement of the optimized enclave image layout is the same for all ofthe unknown processor types.

Example 16 includes the method as defined in example 10, furtherincluding determining a type of a respective one of the unknownprocessor types.

Example 17 includes the method as defined in example 16, wherein thetype of the respective one of the unknown processor types includes atleast one of a static SGX processor or a dynamic SGX processor.

Example 18 includes the method as defined in example 16, furtherincluding associating the optimized enclave image layout with a targetenclave instruction set based on the determined type of the respectiveone of the unknown processor types.

Example 19 is a tangible computer-readable storage disk or storagedevice comprising instructions which, when executed, cause a processorto at least: retrieve configuration parameters associated with anenclave file, calculate a minimum virtual address space value for anenclave image layout based on the configuration parameters, and generatean optimized enclave image layout to allow enclave image execution onunknown target processor types by multiplying the minimum address spacevalue with a virtual address factor to determine an optimized virtualaddress space value for the optimized enclave image layout.

Example 20 includes the tangible computer-readable storage disk orstorage device as defined in example 19, wherein the instructions, whenexecuted, further cause the processor to retrieve a number of candidatethreads associated with the enclave file.

Example 21 includes the tangible computer-readable storage disk orstorage device as defined in example 20, wherein the instructions, whenexecuted, further cause the processor to identify a static heap sizeassociated with the number of candidate threads associated with theenclave file.

Example 22 includes the tangible computer-readable storage disk orstorage device as defined in example 21, wherein the instructions, whenexecuted, further cause the processor to calculate the minimum virtualaddress space value based on the number of candidate threads and thestatic heap size.

Example 23 includes the tangible computer-readable storage disk orstorage device as defined in example 19, wherein the instructions, whenexecuted, further cause the processor to generate the optimized enclaveimage layout with static enclave components and the optimized virtualaddress space value prior to an instantiation phase to facilitate ameasurement of the optimized enclave image layout.

Example 24 includes the tangible computer-readable storage disk orstorage device as defined in example 23, wherein the instructions, whenexecuted, further cause the processor to create the measurement of theoptimized enclave image layout as the same for all of the unknownprocessor types.

Example 25 includes the tangible computer-readable storage disk orstorage device as defined in example 19, wherein the instructions, whenexecuted, further cause the processor to determine a type of arespective one of the unknown processor types.

Example 26 includes the tangible computer-readable storage disk orstorage device as defined in example 25, wherein the instructions, whenexecuted, further cause the processor to associate the optimized enclaveimage layout with a target enclave instruction set based on thedetermined type of the respective one of the unknown processor types.

Example 27 is a system to generate a processor agnostic enclave imagelayout, comprising means for retrieving configuration parametersassociated with an enclave file, means for calculating a minimum virtualaddress space value for an enclave image layout based on theconfiguration parameters, and means for generating an optimized enclaveimage layout to allow enclave image execution on unknown targetprocessor types by multiplying the minimum address space value with avirtual address factor to determine an optimized virtual address spacevalue for the optimized enclave image layout.

Example 28 includes the system as defined in example 27, furtherincluding means for retrieving a number of candidate threads associatedwith the enclave file.

Example 29 includes the system as defined in example 28, wherein theconfiguration parameters include a static heap size associated with thenumber of candidate threads associated with the enclave file.

Example 30 includes the system as defined in example 29, furtherincluding means for calculating the minimum virtual address space valuebased on the number of candidate threads and the static heap size.

Example 31 includes the system as defined in example 27, furtherincluding means for generating the optimized enclave image layout withstatic enclave components and the optimized virtual address space valueprior to an instantiation phase to facilitate a measurement of theoptimized enclave image layout.

Example 32 includes the system as defined in example 31, wherein themeasurement of the optimized enclave image layout is the same for all ofthe unknown processor types.

Example 33 includes the system as defined in example 27, furtherincluding means for determining a type of a respective one of theunknown processor types.

Example 34 includes the system as defined in example 33, wherein thetype of the respective one of the unknown processor types includes atleast one of a static SGX processor or a dynamic SGX processor.

Example 35 includes the system as defined in example 33, furtherincluding means for associating the optimized enclave image layout witha target enclave instruction set based on the determined type of therespective one of the unknown processor types.

Although certain example methods, apparatus and articles of manufacturehave been disclosed herein, the scope of coverage of this patent is notlimited thereto. On the contrary, this patent covers all methods,apparatus and articles of manufacture fairly falling within the scope ofthe claims of this patent.

1. An apparatus to generate a processor agnostic enclave image layout,comprising: an image file retriever to retrieve configuration parametersassociated with an enclave file; and an address space manager to:calculate a minimum virtual address space value for an enclave imagelayout based on the configuration parameters; and generate an optimizedenclave image layout to allow enclave image execution on unknown targetprocessor types by multiplying the minimum address space value with avirtual address factor to determine an optimized virtual address spacevalue for the optimized enclave image layout.
 2. An apparatus as definedin claim 1, wherein the image file retriever is to retrieve a number ofcandidate threads associated with the enclave file.
 3. An apparatus asdefined in claim 2, wherein the configuration parameters include astatic heap size associated with the number of candidate threadsassociated with the enclave file.
 4. An apparatus as defined in claim 3,wherein the address space manager is to calculate the minimum virtualaddress space value based on the number of candidate threads and thestatic heap size.
 5. An apparatus as defined in claim 1, wherein theaddress space manager is to generate the optimized enclave image layoutwith static enclave components and the optimized virtual address spacevalue prior to an instantiation phase to facilitate a measurement of theoptimized enclave image layout.
 6. (canceled)
 7. An apparatus as definedin claim 1, further including a software guard extension (SGX)identifier to determine a type of a respective one of the unknownprocessor types.
 8. An apparatus as defined in claim 7, wherein the typeof the respective one of the unknown processor types includes at leastone of a static SGX processor or a dynamic SGX processor.
 9. (canceled)10. A method to generate a processor agnostic enclave image layout,comprising: retrieving configuration parameters associated with anenclave file; calculating a minimum virtual address space value for anenclave image layout based on the configuration parameters; andgenerating an optimized enclave image layout to allow enclave imageexecution on unknown target processor types by multiplying the minimumaddress space value with a virtual address factor to determine anoptimized virtual address space value for the optimized enclave imagelayout.
 11. A method as defined in claim 10, further includingretrieving a number of candidate threads associated with the enclavefile.
 12. A method as defined in claim 11, wherein the configurationparameters include a static heap size associated with the number ofcandidate threads associated with the enclave file.
 13. A method asdefined in claim 12, further including calculating the minimum virtualaddress space value based on the number of candidate threads and thestatic heap size.
 14. A method as defined in claim 10, further includinggenerating the optimized enclave image layout with static enclavecomponents and the optimized virtual address space value prior to aninstantiation phase to facilitate a measurement of the optimized enclaveimage layout.
 15. A method as defined in claim 14, wherein themeasurement of the optimized enclave image layout is the same for all ofthe unknown processor types.
 16. A method as defined in claim 10,further including determining a type of a respective one of the unknownprocessor types.
 17. (canceled)
 18. (canceled)
 19. At least one tangiblecomputer-readable storage disk or storage device comprising instructionswhich, when executed, cause a processor to at least: retrieveconfiguration parameters associated with an enclave file; calculate aminimum virtual address space value for an enclave image layout based onthe configuration parameters; and generate an optimized enclave imagelayout to allow enclave image execution on unknown target processortypes by multiplying the minimum address space value with a virtualaddress factor to determine an optimized virtual address space value forthe optimized enclave image layout.
 20. A tangible computer-readablestorage disk or storage device as defined in claim 19, wherein theinstructions, when executed, further cause the processor to retrieve anumber of candidate threads associated with the enclave file. 21.(canceled)
 22. (canceled)
 23. A tangible computer-readable storage diskor storage device as defined in claim 19, wherein the instructions, whenexecuted, further cause the processor to generate the optimized enclaveimage layout with static enclave components and the optimized virtualaddress space value prior to an instantiation phase to facilitate ameasurement of the optimized enclave image layout.
 24. A tangiblecomputer-readable storage disk or storage device as defined in claim 23,wherein the instructions, when executed, further cause the processor tocreate the measurement of the optimized enclave image layout as the samefor all of the unknown processor types.
 25. A tangible computer-readablestorage disk or storage device as defined in claim 19, wherein theinstructions, when executed, further cause the processor to determine atype of a respective one of the unknown processor types.
 26. A tangiblecomputer-readable storage disk or storage device as defined in claim 25,wherein the instructions, when executed, further cause the processor toassociate the optimized enclave image layout with a target enclaveinstruction set based on the determined type of the respective one ofthe unknown processor types.